Many software applications, such as video games, include a file input output (I/O) scheduler to make media access within an application more efficient and reliable. A file I/O scheduler (“FIOS”) is a middleware layer for accessing files with several parts including a scheduler and optional I/O filter layers. The scheduler is typically designed to optimally sort I/O requests so that they complete in the shortest possible time subject to arbitrary deadline and priority constraints. The filter layers may provide additional services such as decompression or caching.
Many different game components require I/O access to files in storage media. Audio components load audio files; game-play engines load level definitions; graphics components load texture maps and models; movie components load audio-video files; and subsystems load large WAD files. The media may be game-delivery media such as optical discs (Universal Media Disc (UMD), compact disc (CD), digital video disc (DVD), Blu-Ray disc (BD), etc), intermediate storage media such as hard disks, or other media types as platforms evolve.
A single application, such as a video game, typically has multiple components, each component having its own I/O requirements. Some require streaming access to media, where the I/O system streams data in the file to the component so the component can present the streamed data in succession to the game player. For example, an audio component typically streams an audio file for soundtrack playback; a movie component streams audio-video content to play back a movie for the player. Other components need only non-streaming access where they retrieve data from the file in chunks for the component to process. These components don't need steady data flow, but chunk delivery timing is often crucial: if an application doesn't receive data when it is needed, performance may suffer.
Video games must often perform a considerable amount of I/O. Game events are often time driven with deadlines that must be met. For example, if a player is traveling from point A to Point B the game needs to have the files for data associated with point B loaded before the player gets there. Game components can use low-level I/O primitives to retrieve data from media, but these primitives don't handle device contention when multiple components require data from the same device at the same time. Jammed-up I/O requests can interrupt streaming data flow or prohibit critical data chunks from getting to a component when needed. Higher-level systems such as 989Sound′s Streamsafe at least provide reliable stream access to files so that streamed data is not interrupted. Unfortunately, such systems allocate only a single data stream and don't handle contention for non-stream data very well. Conventional systems provide no standard layer that resolves contention for normal data access.
Because an application's components typically are not aware of each other's I/O activities, their I/O requests often result in highly inefficient I/O patterns with a substantial amount of overseeking (back-and-forth searches for data). As games grow larger, overseeking and inefficient data retrieval increase. Disk mastering for distribution media such as a CD can help avoid some of this inefficiency through techniques such as duplicating frequently accessed data blocks and distributing them across the disk so a copy will always be nearby no matter where the read head of the storage device is. File systems do not always reveal where data is physically located on a disc, though, so I/O systems cannot always make best use of the data.
It is within this context that embodiments of the present invention arise.